home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-bgp-bgp4ospf-interact-01.txt < prev    next >
Text File  |  1993-03-21  |  49KB  |  1,234 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                       K.  Varadhan
  6. Request for Comments: DRAFT                                       OARnet
  7.                                                                 S. Hares
  8.                                                             NSFnet/Merit
  9.                                                               Y. Rekhter
  10.                                                                      IBM
  11.                                                           March 15, 1993
  12.                   BGP4/IDRP for IP---OSPF Interaction
  13.  
  14.  
  15. Table of Contents
  16.  
  17.  1.  Introduction ....................................................  2
  18.  2.  Reachability Information Exchange ...............................  4
  19.  2.1.  Exporting OSPF information into BGP/IDRP  .....................  4
  20.  2.2.  Importing BGP/IDRP information into OSPF ......................  6
  21.  3.  BGP/IDRP Identifier and OSPF router ID ..........................  7
  22.  4.  Setting OSPF tags, ORIGIN and PATH attributes ...................  8
  23.  4.1.  Semantics of the characteristics bits ......................... 10
  24.  4.2.  Configuration parameters for setting the OSPF tag ............. 12
  25.  4.3.  Manually configured tags ...................................... 12
  26.  4.4.  Automatically generated tags .................................. 13
  27.  4.4.1. Destinations with incomplete path information, PathLength =0 . 13
  28.  4.4.2. Destinations with incomplete path information, PathLength =1 . 13
  29.  4.4.3. Destinations with incomplete path information, PathLength >=1  14
  30.  4.4.4. Destinations with complete path information, PathLength =0 ... 14
  31.  4.4.5. Destinations with complete path information, PathLength =1 ... 15
  32.  4.4.6. Destinations with complete path information, PathLength >=1 .. 16
  33.  4.5.  Miscellaneous tag settings .................................... 16
  34.  4.6.  Summary of the TagType field setting .......................... 17
  35.  5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 17
  36.  6.  Changes from the BGP 3 - OSPF interactions document ............. 18
  37.  7.  Security Considerations ......................................... 19
  38.  8.  Acknowledgements ................................................ 19
  39.  9.  Bibliography .................................................... 20
  40.  10.  Appendix ....................................................... 21
  41.  11.  Author's Address ............................................... 22
  42.  
  43.  
  44. Status of this Memo
  45.  
  46.    This document is an Internet Draft.  Internet Drafts are working
  47.    documents of the Internet Engineering Task Force (IETF), its Areas,
  48.    and its Working Groups.  Note that other groups may also distribute
  49.    working documents as Internet Drafts.
  50.  
  51.    Internet Drafts are draft documents valid for a maximum of six
  52.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  53.  
  54.  
  55.  
  56. Varadhan                                                        [Page 1]
  57.  
  58. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  59.  
  60.  
  61.    other documents at any time.  It is not appropriate to use Internet
  62.    Drafts as reference material or to cite them other than as a
  63.    ``working draft'' or ``work in progress.''
  64.  
  65.    Please check the I-D abstract listing contained in each Internet
  66.    Draft directory to learn the current status of this or any other
  67.    Internet Draft.
  68.  
  69. Abstract
  70.  
  71.    This memo defines the various criteria to be used when designing an
  72.    Autonomous System Border Routers (ASBR) that will run either BGP4 or
  73.    IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
  74.  
  75. 1.  Introduction
  76.  
  77.    This document defines the various criteria to be used when designing
  78.    an Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4]
  79.    or IDRP for IP[IDRP] with other ASBRs external to the AS, and
  80.    OSPF[RFC1247] as its IGP.
  81.  
  82.    All future references of BGP in this document will refer to BGP
  83.    version 4, as defined in [BGP-4].  All reference to IDRP are
  84.    references to the Inter-Domain Routing Protocol (ISO 10747) which has
  85.    been defined by the IDRP for IP document [IDRP] for use in Autonomous
  86.    Systems.
  87.  
  88.    This document defines how the following fields in OSPF and attributes
  89.    in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
  90.    at an ASBR:
  91.  
  92.    IDRP came out of the same work as BGP, and may be consider a follow
  93.    on to BGP-3 and BGP-4.  Most fields defined in the interaction
  94.    between BGP and IDRP are named the same.  Where different, the IDRP
  95.    fields are shown separately.
  96.  
  97.            BGP/IDRP MULTI_EXIT_DISC       vs. OSPF cost and type
  98.  
  99.            BGP ORIGIN and AS_PATH         vs. OSPF tag
  100.            IDRP EXT_INFO and RD_PATH
  101.  
  102.            BGP/IDRP NEXT_HOP              vs. OSPF Forwarding Address
  103.  
  104.            BGP/IDRP LOCAL_PREF            vs. OSPF cost
  105.  
  106.    IDRP contains an RD_PATH field which serves the same purpose as an
  107.    AS_PATH field for IDRP for IP.  In this document, we will use the
  108.    term PATH to refer to the BGP AS_PATH, or the IDRP RD_PATH depending
  109.  
  110.  
  111.  
  112. Varadhan                                                        [Page 2]
  113.  
  114. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  115.  
  116.  
  117.    on the context of the protocol being used.
  118.  
  119.    Both IDRP and BGP provide a mechanism to indicate whether the routing
  120.    information was originated via IGP, or some other means.  In IDRP, if
  121.    a route information is originated by means other than an IGP, then
  122.    the EXT_INFO attribute is present.  Likewise, in BGP, if a route
  123.    information is originated by means other than an IGP, then the ORIGIN
  124.    attribute is set to <EGP> or <INCOMPLETE>.  For the rest of the
  125.    document, we will distinguish between the two cases:
  126.  
  127.         (a)  Route information was originated via IGP
  128.  
  129.         (b)  Route information was originated by some other means.
  130.  
  131.    The former case is realized in IDRP by not including the EXT_INFO
  132.    attribute, and in BGP by setting the BGP ORIGIN=<IGP>;  The latter
  133.    case is realized by including the EXT_INFO attribute in IDRP, and by
  134.    setting the BGP ORIGIN=<EGP>.  For the rest of the document, we will
  135.    use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
  136.    ORIGIN=<EGP> to refer to the latter.
  137.  
  138.    One other difference between IDRP and BGP remains.  IDRP for IP iden-
  139.    tifies an autonomous system by an identifier of variable length that
  140.    is syntactically identical to an NSAP address prefix, and explicitly
  141.    embeds the autonomous system number[IDRP-IP].  BGP identifies an
  142.    autonomous system just by an autonomous system number.  Since there
  143.    is a one-to-one mapping between how an autonomous system is identi-
  144.    fied in IDRP and in BGP, for the rest of the document, we shall iden-
  145.    tify an autonomous system by its autonomous system number.
  146.  
  147.    For a more general treatise on routing and route exchange problems,
  148.    please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
  149.  
  150.    This document uses the two terms ``Autonomous System'' and ``Routing
  151.    Domain.''  The definitions for the two are below:
  152.  
  153.    The term Autonomous System is the same as is used in the BGP
  154.    RFC[RFC1267], given below:
  155.  
  156.      ``The use of the term Autonomous System here stresses the fact
  157.      that, even when multiple IGPs and metrics are used, the
  158.      administration of an AS appears to other ASs to have a single
  159.      coherent interior routing plan and presents a consistent picture of
  160.      what destinations are reachable through it.  From the standpoint of
  161.      exterior routing, an AS can be viewed as monolithic: reachability
  162.      to destinations directly connected to the AS must be equivalent
  163.      from all border gateways of the AS.''
  164.  
  165.  
  166.  
  167.  
  168. Varadhan                                                        [Page 3]
  169.  
  170. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  171.  
  172.  
  173.    The term Routing Domain was first used in [ROUTE-LEAKING] and is
  174.    given below:
  175.  
  176.           ``A Routing Domain is a collection of routers which coordinate
  177.           their routing knowledge using a single [instance of a] routing
  178.           protocol.''
  179.  
  180.      By definition, a Routing Domain forms a single Autonomous System,
  181.      but an Autonomous System may be composed of a collection of Routing
  182.      Domains.
  183.  
  184.      BGP, IDRP and OSPF have the concept of a set of reachable
  185.      destinations.  This set is called NLRI or Network Layer
  186.      Reachability Information.  The set can be represented either as an
  187.      IP address prefix, or an address, mask pair.  Note that if the mask
  188.      is contiguous in the latter, then the two representations are
  189.      equivalent.  In this document, we use the term `address/mask pair''
  190.      in the context of OSPF, and ``destination'' or ``set of reachable
  191.      destinations'' in the context of BGP or IDRP.
  192.  
  193.      This document follows the conventions embodied in the Host
  194.      Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
  195.      "SHOULD," and "MAY" for the various requirements.
  196.  
  197.      A minimal implementation of BGP/IDRP OSPF exchange SHOULD not
  198.      import BGP/IDRP routes into the OSPF RD (section 2.1, bullet 1),
  199.      MUST set the BGP/IDRP identifier to be the same as OSPF router ID
  200.      (section 3), MUST set the OSPF tag accurately (section 4).  It is
  201.      strongly recommended that implementors implement more than a
  202.      minimalistic specification.
  203.  
  204. 2.  Reachability Information Exchange
  205.  
  206.    This section discusses the constraints that must be met to exchange
  207.    the set of reachable destinations between an external BGP/IDRP peer
  208.    from another AS and internal OSPF address/mask pairs.
  209.  
  210.    2.1.  Exporting OSPF information into BGP
  211.  
  212.  
  213.       1.   The administrator MUST be able to selectively export
  214.            address/mask pairs into BGP/IDRP via an appropriate filter
  215.            mechanism.
  216.  
  217.            This filter mechanism MUST support such control with the
  218.            granularity of an address/mask pair.
  219.  
  220.            This filter mechanism will be the primary method of
  221.  
  222.  
  223.  
  224. Varadhan                                                        [Page 4]
  225.  
  226. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  227.  
  228.  
  229.            aggregation of OSPF internal and type 1 and type 2 external
  230.            routes within the AS into BGP/IDRP.
  231.  
  232.            Additionally, the administrator MUST be able to filter based
  233.            on the OSPF tag and the various sub-fields of the OSPF tag.
  234.            The settings of the tag and the sub-fields are defined in
  235.            section 4 in more detail.
  236.  
  237.            o    The default MUST be to export no routes from OSPF into
  238.                 BGP/IDRP.  A single configuration parameter MUST permit
  239.                 all OSPF inter-area and intra-area address/mask pairs to
  240.                 be exported into BGP/IDRP.
  241.  
  242.                 OSPF external address/mask pairs of type 1 and type 2
  243.                 MUST never be exported into BGP/IDRP unless they are
  244.                 explicitly configured.
  245.  
  246.       2.   An address/mask pair having a non-contiguous mask MUST not be
  247.            exported to BGP/IDRP.
  248.  
  249.       3.   When configured to export an address/mask pair from OSPF into
  250.            BGP/IDRP, the ASBR MAY advertise the route containing the set
  251.            of reachable destinations via BGP/IDRP as soon as at least
  252.            one of the destinations in the address/mask pair is
  253.            determined to be reachable via OSPF; it MUST stop advertising
  254.            the route containing the set of reachable destinations when
  255.            none of the destinations in the address/mask pair is
  256.            reachable via OSPF.
  257.  
  258.       4.   The network administrator MUST be able to statically
  259.            configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
  260.            be used for any route.
  261.  
  262.            o    The default MUST be to omit the MULTI_EXIT_DISC in the
  263.                 route advertised via BGP/IDRP.
  264.  
  265.       5.   An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
  266.            mechanism to set up a minimum amount of time that must elapse
  267.            between the learning of a new address/mask pair via OSPF and
  268.            subsequent advertisement of the address/mask pair via
  269.            BGP/IDRP to the external neighbours.
  270.  
  271.            o    The default value for this setting MUST be 0, indicating
  272.                 that the address/mask pair is to be advertised to the
  273.                 neighbour BGP/IDRP peers instantly.
  274.  
  275.                 Note that BGP and IDRP mandate a mechanism to dampen the
  276.                 inbound advertisements from adjacent neighbours.  See
  277.  
  278.  
  279.  
  280. Varadhan                                                        [Page 5]
  281.  
  282. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  283.  
  284.  
  285.                 the variable MinRouteAdvertisementInterval in section
  286.                 9.2.3.1, [BGP-4] or in section 7.17.3.1, [DIS ballot
  287.                 IDRP].
  288.  
  289.    2.2.  Importing BGP/IDRP information into OSPF
  290.  
  291.       1.   A BGP/IDRP speaker can advertise an externally received route
  292.            into OSPF if this is route is selected at the completion of
  293.            the phase 2 route selection process, which includes the tie
  294.            break mechanism.
  295.  
  296.       2.   BGP/IDRP implementations SHOULD allow an AS to control
  297.            announcements of BGP/IDRP learned set of reachable
  298.            destinations into OSPF.  Implementations SHOULD support such
  299.            control with the granularity of a single destination.
  300.  
  301.            Implementations SHOULD also support such control with the
  302.            granularity of an autonomous system, where the autonomous
  303.            system may be either the autonomous system that originated
  304.            the information or the autonomous system that advertised the
  305.            information to the local system (adjacent autonomous system).
  306.  
  307.            o    The default MUST be to import nothing from BGP/IDRP into
  308.                 OSPF.  Administrators must configure every destination
  309.                 they wish to import.
  310.  
  311.                 A configuration parameter MAY allow an administrator to
  312.                 configure an ASBR to import all the set of reachable
  313.                 destinations from BGP/IDRP into the OSPF routing domain.
  314.  
  315.       3.   The administrator MUST be able to configure the OSPF cost and
  316.            the OSPF metric type of every destination imported into OSPF.
  317.  
  318.            o    The OSPF cost MUST default to the LOCAL_PREF value; the
  319.                 OSPF metric type MUST default to type 2.
  320.  
  321.       4.   Information learned via BGP/IDRP from peers within the same
  322.            AS MUST not be imported into OSPF.
  323.  
  324.       5.   The ASBR MUST never generate a default destination into the
  325.            OSPF routing domain unless explicitly configured to do so.
  326.  
  327.            A default destination is a set of all possible destinations.
  328.            By convention, it is represented as a prefix of 0 length or a
  329.            mask of all zeroes.
  330.  
  331.            A possible criterion for generating default into an IGP is to
  332.            allow the administrator to specify a set of (set of reachable
  333.  
  334.  
  335.  
  336. Varadhan                                                        [Page 6]
  337.  
  338. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  339.  
  340.  
  341.            destinations, PATH, default cost, default type) tuples.  If
  342.            the ASBR learns of at least one of the destinations in the
  343.            set of reachable destinations, with the corresponding PATH,
  344.            then it generates a default destination into the OSPF routing
  345.            domain, with the appropriate cost and type.  The lowest cost
  346.            route will then be injected into the OSPF routing domain.
  347.  
  348.            This is the recommended method for originating default
  349.            destinations in the OSPF routing domain.
  350.  
  351.       6.   Note that [RFC1247] requires the network number to be used as
  352.            the Link State ID.  This will produce a conflict if the ASBR
  353.            tries to import two destinations, differing only in their
  354.            prefix length.  An implementation conforming to [RFC1247]
  355.            MUST, in this case, drop the more specific route, i.e. the
  356.            route corresponding to the longer prefix in the reachability
  357.            information.  The OSPF WG is working on revising [RFC1247].
  358.            The revised version will incorporate hooks to handle the
  359.            conflict.
  360.  
  361. 3.  BGP/IDRP Identifier and OSPF router ID
  362.  
  363.    The BGP/IDRP identifier MUST be the same as the OSPF router id at all
  364.    times that the router is up.
  365.  
  366.    Note that [BGP-4] requires that the BGP identifier be an address
  367.    assigned to the BGP speaker.
  368.  
  369.    In the case of IDRP, the IDRP protocol does not explicitly carry the
  370.    identity of the IDRP speaker.  An implicit notion of the identity of
  371.    the IDRP speaker can be obtained by examining the source address in
  372.    the IP packets carrying the IDRP information.  Therefore, all IDRP
  373.    speakers participating in the OSPF protocol MUST bind the IDRP
  374.    identifier to be the address of the OSPF router id.
  375.  
  376.    This characteristic is required for two reasons.
  377.  
  378.      i    Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
  379.           belong to the same autonomous system.
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392. Varadhan                                                        [Page 7]
  393.  
  394. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  395.  
  396.  
  397.  
  398.                                      +-----+
  399.                                      | RT3 |
  400.                                      +-----+
  401.                                         |
  402.  
  403.                           Autonomous System running OSPF
  404.  
  405.                                  /               \
  406.  
  407.                              +-----+          +-----+
  408.                              | RT1 |          | RT2 |
  409.                              +-----+          +-----+
  410.  
  411.  
  412.           Both RT1 and RT2 can reach an external destination X and
  413.           import this information into the OSPF routing domain.  RT3 is
  414.           advertising this information about destination X to other
  415.           external BGP/IDRP speakers.  RT3 must use the OSPF router ID
  416.           to determine whether it is using RT1 or RT2 to forward packets
  417.           to destination X and hence build the correct PATH to advertise
  418.           to other external speakers.
  419.  
  420.           More precisely, RT3 MUST determine which ASBR it is using to
  421.           reach destination X by matching the OSPF router ID for its
  422.           route to destination X with the BGP identifier of one of the
  423.           ASBRs, or the IP source address of the IDRP protocol packet
  424.           from one of the ASBRs; it MAY then generate the corresponding
  425.           network layer reachability information for further
  426.           advertisement to external BGP/IDRP peers.
  427.  
  428.      ii   It will be convenient for the network administrator looking at
  429.           an ASBR to correlate different BGP/IDRP and OSPF information
  430.           based on the identifier.
  431.  
  432. 4.  Setting OSPF tags, ORIGIN and PATH attributes
  433.  
  434.    The OSPF external route tag is a ``32-bit field attached to each
  435.    external route . . . It may be used to communicate information
  436.    between AS boundary routers; the precise nature of such information
  437.    is outside the scope of [the] specification.''[RFC1247]
  438.  
  439.    OSPF imports information from various routing protocols at all its
  440.    ASBRs.  In some instances, it is possible to use protocols other than
  441.    EGP or BGP across autonomous systems.  It is important, in BGP/IDRP,
  442.    to differentiate between reachable destinations that are external to
  443.    the OSPF routing domain but must be considered internal to the AS, as
  444.    opposed to reachable destinations that are external to the AS.
  445.  
  446.  
  447.  
  448. Varadhan                                                        [Page 8]
  449.  
  450. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  451.  
  452.  
  453.    Reachable destinations that are internal to the AS and that may or
  454.    may not be external to the OSPF routing domain will not come to the
  455.    various BGP/IDRP speakers from other BGP/IDRP speakers within the
  456.    same autonomous system via BGP/IDRP.  Therefore, ASBRs running
  457.    BGP/IDRP must have knowledge of this class of reachable destinations
  458.    so that they can advertise these destinations to the various external
  459.    AS without waiting for BGP/IDRP updates from other BGP/IDRP speakers
  460.    within the same autonomous system about these destinations.
  461.  
  462.    Additionally, in the specific instance of an AS intermixing routers
  463.    running EGP and BGP/IDRP as external gateway routing protocols, using
  464.    OSPF as an IGP, then within the autonomous system, it may not be
  465.    necessary to run BGP/IDRP with every ASBR running EGP and not running
  466.    BGP/IDRP, if this information can be carried in the OSPF tag field.
  467.  
  468.    We use the external route tag field in OSPF to intelligently set the
  469.    ORIGIN and PATH attributes in BGP/IDRP.  These attributes are well-
  470.    known, mandatory attributes in the respective protocols.  The exact
  471.    mechanism for setting the tags is defined below.
  472.  
  473.    The tag is broken up into sub-fields shown below.  The various sub-
  474.    fields specify the characteristics of the set of reachable
  475.    destinations imported into the OSPF routing domain.
  476.  
  477.    The high bit of the OSPF tag is known as the ``Automatic'' bit.  When
  478.    this bit is set to 1, the following sub-fields apply:
  479.  
  480.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  481.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  482.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  483.      |a|c|p l|     ArbitraryTag      |       AutonomousSystem        |
  484.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  485.  
  486.  
  487.      a    is 1 bit called the Automatic bit, indicating that the
  488.           Completeness and PathLength bits have been generated
  489.           automatically by a router.  The meaning of this characteristic
  490.           and its setting are defined below.
  491.  
  492.      c    is 1 bit of Completeness information.  The meaning of this
  493.           characteristic and its settings are defined below.
  494.  
  495.      pl   are 2 bits of PathLength information.  The meaning of this
  496.           characteristic and its setting are defined below.
  497.  
  498.      ArbitraryTag
  499.           is 12 bits of tag information, which defaults to 0 but can be
  500.           configured to anything else.
  501.  
  502.  
  503.  
  504. Varadhan                                                        [Page 9]
  505.  
  506. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  507.  
  508.  
  509.           Note: for IDRP the value must be zero if the standard fixed
  510.           format header to the AS number is used.  Otherwise, the value
  511.           indicates a index into a table of fixed headers for the IDRP
  512.           Routing Domain Identifier.
  513.  
  514.      AutonomousSystem (or ``AS'')
  515.           is 16 bits, indicating the AS number corresponding to the set
  516.           of reachable destinations, 0 if the set of reachable
  517.           destinations is to be considered as part of the local AS.
  518.  
  519.           local_AS
  520.                The term `local_AS' refers to the AS number of the local
  521.                OSPF routing domain.
  522.  
  523.           next_hop_AS
  524.                `next_hop_AS' refers to the AS number of an external BGP
  525.                peer.
  526.  
  527.      When the Automatic bit is set to 0, the following sub-fields apply:
  528.  
  529.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  530.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  531.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.      |a|                          LocalInfo                          |
  533.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.  
  535.  
  536.      a    is 1 bit called the Automatic bit, set to 0.
  537.  
  538.      LocalInfo
  539.           is 31 bits of an arbitrary value, manually configured by the
  540.           network administrator.
  541.  
  542.      The format of the tag for various values of the characteristics
  543.      bits is defined below.
  544.  
  545.    4.1.  Semantics of the characteristics bits
  546.  
  547.       The Completeness and PathLength characteristics bits define the
  548.       characteristic of the set of reachable destinations imported into
  549.       OSPF from other ASBRs in the autonomous system.  This setting is
  550.       then used to set the ORIGIN and PATH attributes when re-exporting
  551.       these reachable destinations to an external BGP/IDRP speaker.
  552.  
  553.       o    The Automatic characteristic bit is set when the Completeness
  554.            and PathLength characteristics bits are automatically set by
  555.            a border router.
  556.  
  557.  
  558.  
  559.  
  560. Varadhan                                                       [Page 10]
  561.  
  562. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  563.  
  564.  
  565.            For backward compatibility, the Automatic bit must default to
  566.            0 and the network administrator must have a mechanism to
  567.            enable automatic tag generation.  Nothing must be inferred
  568.            about the characteristics of the OSPF address/mask pair from
  569.            the tag bits, unless the tag has been automatically
  570.            generated.
  571.  
  572.       o    The Completeness characteristic bit is set when the source of
  573.            the incoming route is known precisely, for instance, from an
  574.            IGP within the local autonomous system or EGP at one of the
  575.            autonomous system's boundaries.  It refers to the status of
  576.            the path information carried by the routing protocol.
  577.  
  578.       o    The PathLength characteristic sub-field is set depending on
  579.            the length of the PATH that the protocol could have carried
  580.            when importing the reachability information into the OSPF
  581.            routing domain.  The length bits will indicate whether the
  582.            PATH attribute for the length is zero, one, or greater than
  583.            one.
  584.  
  585.            Reachable destinations imported from an IGP will usually have
  586.            a PATH of length of 0, reachable destinations imported from
  587.            an EGP will have an PATH of length 1, BGP/IDRP and routing
  588.            protocols that support complete path information, either as
  589.            BGP AS_PATHs or IDRP routing domain paths(RD_PATHs), will
  590.            indicate a path greater than 1.
  591.  
  592.            The OSPF tag is not wide enough to carry path information
  593.            about reachable destinations that have an associated
  594.            PathLength greater than one.  Path information about these
  595.            destinations will have to be carried via BGP/IDRP to other
  596.            ASBRs with the same autonomous system.  Such destinations
  597.            must not be exported from OSPF into BGP/IDRP.
  598.  
  599.       In the following sections, the code YES will have value 1, and the  |
  600.       code NO will have value 0.
  601.  
  602.    4.2.  Configuration parameters for setting the OSPF tag
  603.  
  604.       o    There MUST be a mechanism to enable automatic generation of
  605.            the tag characteristic bits.
  606.  
  607.       o    Configuration of an ASBR running OSPF MUST include the
  608.            capability to associate a tag value, for the ArbitraryTag, or
  609.            LocalInfo sub-field of the OSPF tag, with each instance of a
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616. Varadhan                                                       [Page 11]
  617.  
  618. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  619.  
  620.  
  621.            routing protocol.
  622.  
  623.       o    Configuration of an ASBR running OSPF MUST include the
  624.            capability to associate an AS number with each instance of a
  625.            routing protocol.
  626.  
  627.            Associating an AS number with an instance of an IGP is
  628.            equivalent to flagging those set of reachable destinations
  629.            imported from the IGP to be external destinations outside the
  630.            local autonomous system.
  631.  
  632.            Specifically, when the IGP is RIP[RFC1058], it SHOULD be
  633.            possible to associate a tag and/or an AS number with every
  634.            interface running RIP on the ASBR.
  635.  
  636.       4.3.  Manually configured tags
  637.  
  638.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  639.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  640.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  641.       |0|                          LocalInfo                          |
  642.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  643.  
  644.          This tag setting  corresponds  to  the  administrator  manually
  645.          setting   the  tag  bits.   Nothing  MUST  inferred  about  the
  646.          characteristics  of   the   set   of   reachable   destinations
  647.          corresponding to this tag setting.
  648.  
  649.          For backward compatibility  with  existing  implementations  of
  650.          OSPF  currently deployed in the field, this MUST be the default
  651.          setting  for  importing  destinations  into  the  OSPF  routing
  652.          domain.   There  MUST  be  a  mechanism to enable automatic tag
  653.          generation for imported destinations.
  654.  
  655.          The OSPF tag to BGP/IDRP attribute mappings for these reachable
  656.          destinations MUST be
  657.  
  658.          Automatic=NO, LocalInfo=Arbitrary_Value =>                       |
  659.                                            ORIGIN=<EGP>, PATH=<local_AS>  |
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672. Varadhan                                                       [Page 12]
  673.  
  674. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  675.  
  676.  
  677.    4.4.  Automatically generated tags
  678.  
  679.       4.4.1. Destinations with incomplete path information, PathLength =
  680.          0
  681.  
  682.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  683.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  684.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  685.       |1|0|0|0|     ArbitraryTag      |       AutonomousSystem        |
  686.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  687.  
  688.          These are reachable destinations imported from routing
  689.          protocols with incomplete path information and cannot or may
  690.          not carry the neighbour AS or AS path (and hence the IDRP
  691.          RD_PATH) as part of the routing information.
  692.  
  693.          The OSPF tag to BGP/IDRP attribute mappings for these
  694.          destinations MUST be
  695.  
  696.          Automatic=YES, Completeness=NO, PathLength=00, AS=0 =>
  697.                                            ORIGIN=<EGP>, PATH=<local_AS>
  698.  
  699.       4.4.2. Destinations with incomplete path information, PathLength =
  700.          1
  701.  
  702.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  703.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  704.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  705.       |1|0|0|1|     ArbitraryTag      |       AutonomousSystem        |
  706.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  707.  
  708.          These are reachable destinations imported from routing
  709.          protocols with incomplete path information.  The neighbour AS
  710.          (and therefore IDRP RD) is carried in the routing information.
  711.  
  712.          The OSPF tag to BGP/IDRP attribute mappings for these
  713.          destinations MUST be
  714.  
  715.          Automatic=YES, Completeness=NO, PathLength=01, AS=<next_hop_AS>
  716.                            => ORIGIN=<EGP>, PATH=<local_AS, next_hop_AS>
  717.  
  718.          This setting SHOULD be used for importing reachable
  719.          destinations from EGP into the OSPF routing domain.  This
  720.          setting MAY also be used when importing reachable destinations
  721.          from BGP/IDRP whose ORIGIN=<EGP> and PATH=<next_hop_AS>; if the
  722.          BGP/IDRP learned route has no other transitive attributes, then
  723.          its propagation via BGP/IDRP to ASBRs internal to the
  724.          autonomous system MAY be suppressed.
  725.  
  726.  
  727.  
  728. Varadhan                                                       [Page 13]
  729.  
  730. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  731.  
  732.  
  733.       4.4.3. Destinations with incomplete path information, PathLength
  734.          >= 1
  735.  
  736.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  737.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  738.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  739.       |1|0|1|0|     ArbitraryTag      |       AutonomousSystem        |
  740.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  741.  
  742.          These are reachable destinations imported from routing
  743.          protocols with truncated path information.
  744.  
  745.          The OSPF tag to BGP/IDRP attribute mappings for these
  746.          destinations MUST be
  747.  
  748.          Automatic=YES, Completeness=NO, PathLength=10, AS=don't care
  749.  
  750.          These are imported by a border router, which is running
  751.          BGP/IDRP to a stub domain, and not running BGP/IDRP to other
  752.          ASBRs in the same autonomous system.  This causes a truncation
  753.          of the PATH.  These destinations MUST not be re-exported into
  754.          BGP/IDRP at another ASBR.
  755.  
  756.       4.4.4. Destinations with complete path information, PathLength = 0
  757.  
  758.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  759.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  760.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  761.       |1|1|0|0|     ArbitraryTag      |       AutonomousSystem        |
  762.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  763.  
  764.          These are reachable destinations imported from routing
  765.          protocols with either complete path information or are known to
  766.          be complete through means other than that carried by the
  767.          routing protocol.
  768.  
  769.          The OSPF tag to BGP/IDRP attribute mappings for these
  770.          destinations MUST be
  771.          Automatic=YES, Completeness=YES, PathLength=00, AS=00
  772.                                         => ORIGIN=<EGP>, PATH=<local_AS>
  773.          This SHOULD be used for importing reachable destinations into
  774.          OSPF from an IGP.
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784. Varadhan                                                       [Page 14]
  785.  
  786. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  787.  
  788.  
  789.       4.4.5. Destinations with complete path information, PathLength = 1
  790.  
  791.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  792.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  793.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  794.       |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
  795.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  796.  
  797.          These are reachable destinations imported from routing
  798.          protocols with either complete path information, or are known
  799.          to be complete through means other than that carried by the
  800.          routing protocol.  The routing protocol also has additional
  801.          information about the next hop AS or RD, the destination was
  802.          learned from.
  803.  
  804.          The OSPF tag to BGP/IDRP attribute mappings for these
  805.          destination MUST be
  806.  
  807.          Automatic=YES, Completeness=YES, PathLength=01, AS=next_hop_AS
  808.                            => ORIGIN=<IGP>, PATH=<local_AS, next_hop_AS>
  809.  
  810.          This setting SHOULD be used when the administrator explicitly
  811.          associates an AS number with an instance of an IGP.  This
  812.          setting MAY also be used when importing reachable destinations
  813.          from BGP/IDRP whose ORIGIN=<IGP> and PATH=<next_hop_AS>; if the
  814.          BGP/IDRP learned route has no other transitive attributes, then
  815.          its propagation via BGP/IDRP to other ASBRs internal to the
  816.          autonomous system MAY be suppressed.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840. Varadhan                                                       [Page 15]
  841.  
  842. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  843.  
  844.  
  845.       4.4.6. Destinations with complete path information, PathLength >=1
  846.  
  847.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  848.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  849.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  850.       |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
  851.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  852.  
  853.          These are reachable destinations imported from routing
  854.          protocols with complete path information and carry the AS path
  855.          information as part of the routing information.
  856.  
  857.          The OSPF tag MUST be set to
  858.  
  859.          Automatic=YES, Completeness=YES, PathLength=10, AS=don't care
  860.  
  861.          These destinations MUST not be exported into BGP/IDRP because
  862.          these destinations are already imported from BGP/IDRP into the
  863.          OSPF RD.  Hence, it is assumed that the BGP/IDRP speaker will
  864.          convey this information to other BGP/IDRP speakers within the
  865.          same autonomous system via BGP/IDRP.  As ASBR learning of such
  866.          a destination MUST wait for the BGP update from its internal
  867.          neighbours before advertising it to external BGP/IDRP peers.
  868.  
  869.          Note that an implementation MAY import reachable destinations
  870.          from BGP/IDRP with a path length of 1 and no other transitive
  871.          attributes directly into OSPF and not send these routes via
  872.          BGP/IDRP to ASBRs within the same autonomous system.  In this
  873.          situation, it MUST use tag settings corresponding to 4.4.2, or
  874.          4.4.5.
  875.  
  876.    4.5.  Miscellaneous tag settings
  877.  
  878.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  879.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  880.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  881.       |1|x|1|1|              Reserved  for  future  use               |
  882.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  883.  
  884.       The value of PathLength=11 is reserved during automatic tag
  885.       generation.  Routers must not generate such a tag when importing
  886.       reachable destinations into the OSPF routing domain.  ASBRs must
  887.       ignore tags which indicate a PathLength=11.
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896. Varadhan                                                       [Page 16]
  897.  
  898. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  899.  
  900.  
  901.    4.6.  Summary of the tag sub-field setting
  902.  
  903.       The following table summarizes the various combinations of
  904.       automatic tag settings for the Completeness and PathLength sub-
  905.       field of the OSPF tag and the default behaviour permitted for each
  906.       setting.
  907.  
  908.                   Completeness := 0 | 1
  909.                   PathLength := 00 | 01 | 10 | 1
  910.                   ORIGIN := <IGP> | <EGP>
  911.                   PATH := valid AS path settings as defined in BGP [BGP-4],
  912.                               and IDRP for IP[IDRP].
  913.  
  914. PathLength ==> 00               01                   10                11
  915. Completeness
  916.   ||     +--------------------------------------------------------------------
  917.   vv     |
  918.   =  NO  |    <EGP>            <EGP>             never export       reserved
  919.          |  <local_AS>  <local_AS,next_hop_AS>
  920.          |
  921.   = YES  |    <IGP>            <IGP>             out of band        reserved
  922.          |  <local_AS>  <local_AS,next_hop_AS>
  923.          |
  924.  
  925.       The "out of band" in the table above implies that OSPF will not be
  926.       able to carry everything that BGP needs in its routing
  927.       information.  Therefore, some other means must be found to carry
  928.       this information.  In BGP, this is done by running BGP to other
  929.       ASBRs within the same autonomous system.
  930.  
  931. 5.  Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute
  932.  
  933.    Forwarding addresses are used to avoid extra hops between multiple
  934.    routers that share a common network and that speak different routing
  935.    protocols with each other on the common network.
  936.  
  937.    Both BGP/IDRP and OSPF have equivalents of forwarding addresses.  In
  938.    BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory
  939.    attribute.  OSPF has a Forwarding address field.  We will discuss how
  940.    these are to be filled in various situations.
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952. Varadhan                                                       [Page 17]
  953.  
  954. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  955.  
  956.  
  957.  
  958.    Consider the 4 router situation below:
  959.  
  960.    RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
  961.    RT1 and RT3 are talking BGP/IDRP with each other.  RT3 and RT4 are
  962.    talking OSPF with each other.
  963.  
  964.             +-----+                 +-----+
  965.             | RT1 |                 | RT2 |
  966.             +-----+                 +-----+
  967.                |                       |            common network
  968.             ---+-----------------------+--------------------------
  969.             <BGP/IDRP> |                       |
  970.                     +-----+     <OSPF>      +-----+
  971.                     | RT3 |                 | RT4 |
  972.                     +-----+                 +-----+
  973.  
  974.  
  975.      - Importing a reachable destination into OSPF:
  976.           When importing a destination from BGP/IDRP into OSPF, RT3 MUST
  977.           always fill the OSPF Forwarding Address with the BGP/IDRP
  978.           NEXT_HOP attribute for the destination.
  979.  
  980.      - Exporting a reachable destination into BGP:
  981.           When exporting set of reachable destinations internal to the
  982.           OSPF routing domain from OSPF to BGP/IDRP, if all the
  983.           destinations in the set of reachable destinations are through
  984.           RT4, then RT3 MAY fill the NEXT_HOP attribute for the set of
  985.           reachable destinations with the address of RT4.  This is to
  986.           avoid requiring packets to take an extra hop through RT3 when
  987.           traversing the AS boundary.  This is similar to the concept of
  988.           indirect neighbour support in EGP[RFC888, RFC827].
  989.  
  990. 6.  Changes from the BGP 3 - OSPF interactions document
  991.  
  992.      o    The use of the term "route" has attained a more complicated
  993.           structure in BGP 4.  This document follows the constraint in
  994.           the manner shown below:
  995.  
  996.           -    The term "set of reachable destinations" is called a NLRI
  997.                in [BGP-4].
  998.  
  999.           -    The term "route" in the BGP context refers to a set of
  1000.                reachable destinations, and the associated attributes for
  1001.                the set.
  1002.  
  1003.           -    The term "route" in the OSPF context refers to the set of
  1004.                reachable destinations, and the cost and the type to
  1005.  
  1006.  
  1007.  
  1008. Varadhan                                                       [Page 18]
  1009.  
  1010. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  1011.  
  1012.  
  1013.                reach destinations.  This is to keep the definitions
  1014.                consistent in the document.
  1015.  
  1016.      o    The notion of exchanging reachability information between BGP
  1017.           4 and OSPF has been updated to handle variable length net mask
  1018.           information.
  1019.  
  1020.      o    The previous term INTER_AS_METRIC in BGP 3 has now been
  1021.           changed to MULTI_EXIT_DISC.
  1022.  
  1023.      o    The default metric to be used for importing BGP information
  1024.           into the OSPF RD is now the LOCAL_PREF attribute, instead of a
  1025.           constant value.
  1026.  
  1027.      o    BGP 4 requires that the BGP identifier be an address assigned
  1028.           to the BGP speaker.  This is dealt with in section 3.
  1029.  
  1030.      o    Section 5 on setting NEXT_HOP attributes and Forwarding
  1031.           Address field has been updated to account for variable length
  1032.           net information.
  1033.  
  1034.      o    Section 2 which requires an ASBR to match the OSPF tag
  1035.           corresponding to a route to the BGP Identifier, can cause
  1036.           potential loops if the AS has equal cost multipath routing
  1037.           amongst the ASBRs.  This scenario is outlined in the Appendix
  1038.           below.
  1039.  
  1040.      o    This section, 6, has been added.
  1041.  
  1042. 7.  Security Considerations
  1043.  
  1044.    Security considerations are not discussed in this memo.
  1045.  
  1046. 8.  Acknowledgements
  1047.  
  1048.    I would like to thank Jeff Honig (Cornell University), John Moy
  1049.    (Proteon, Inc.), Tony Li (cisco Systems), Rob Coltun (Consultant),
  1050.    Dennis Ferguson (ANS, Inc.), and Phil Almquist (Consultant) for their
  1051.    help and suggestions in writing this document, without which I could
  1052.    not have written this document.  I would also like to thank them for
  1053.    giving me the opportunity to write this document, and putting up with
  1054.    my muddlements through various phases of this document.
  1055.  
  1056.    We would also like to thank the countless number of people from the
  1057.    OSPF and BGP working groups who have offered numerous suggestions and
  1058.    comments on the different stages of this document.
  1059.  
  1060.    Thanks also to Bob Braden (ISI), whose suggestions on the earlier
  1061.  
  1062.  
  1063.  
  1064. Varadhan                                                       [Page 19]
  1065.  
  1066. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  1067.  
  1068.  
  1069.    BGP-OSPF document, [RFC1403] were useful even for this one, and have
  1070.    been carried through.
  1071.  
  1072. 9.  Bibliography
  1073.  
  1074.  
  1075. [RFC827]   Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October
  1076.      1982.
  1077.  
  1078. [RFC888]   Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior
  1079.      Gateway Protocol'', January 1984.
  1080.  
  1081. [RFC1058]  Hedrick, Charles, L., ``Routing Information Protocol'', June
  1082.      1988.
  1083.  
  1084. [RFC1122]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1085.      communication layers'', October 1989.
  1086.  
  1087. [RFC1123]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1088.      application and support'', October 1989.
  1089.  
  1090. [RFC1247]  Moy, John, ``The OSPF Specification  Version 2'', January
  1091.      1991.
  1092.  
  1093. [RFC1338]  Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan,
  1094.      ``Supernetting: an Address Assignment and Aggregation Strategy'',
  1095.      June 1992.
  1096.  
  1097. [RFC1403] Varadhan, Kannan; ``BGP OSPF Interaction''; January 1993.
  1098.  
  1099. [ROUTE-LEAKING]  Almquist, Philip, ``Ruminations on Route Leaking'', in
  1100.      preparation.
  1101.  
  1102. [NEXT-HOP]  Almquist, Philip, ``Ruminations on the Next Hop'', in
  1103.      preparation.
  1104.  
  1105. [BGP-4]  Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway
  1106.      Protocol 4 (BGP-4)'', in preparation.
  1107.  
  1108. [IDRP] Hares, Susan; ``IDRP for IP'', in preparation
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Varadhan                                                       [Page 20]
  1121.  
  1122. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  1123.  
  1124.  
  1125. 10.  Appendix
  1126.  
  1127.  
  1128.                                 X
  1129.                                / \
  1130.                               /   \     +----+
  1131.                              /     \   /      \
  1132.                             /    +--------+    |
  1133.                            /     | C1  C2 |    |
  1134.                           |      |Domain C|    |
  1135.                           B      |   C3   |    |
  1136.                           |      +--------+    |
  1137.                            \          /        |
  1138.                             \        /         /
  1139.                              \      /         /
  1140.                               \    /         /
  1141.                             +--------+      /
  1142.                             | A1  A2 |     /
  1143.                             |Domain A|    /
  1144.                             |   A3   |   /
  1145.                             +--------+  /
  1146.                                  \     /
  1147.                                   \   /
  1148.                                    \ /
  1149.                                     S
  1150.  
  1151.  
  1152.    Given the domains, X, A, B, C and C, let domains A and C be running
  1153.    OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2
  1154.    and C1, C2 respectively.  The picture above shows the internal
  1155.    structure of domains A and C only.
  1156.  
  1157.    During steady state, the following are the route advertisements:
  1158.  
  1159.      o    Domain B advertises to A path <B,X>
  1160.  
  1161.      o    ASBR A3 in domain A advertises path <A,B,X> to domain C, at
  1162.           ASBR C2.
  1163.  
  1164.      o    Domain C has two equal cost paths to X: one direct <C,X>, and
  1165.           another through A <C,A,B,X>
  1166.  
  1167.      o    BR C3 in domain C advertises to A2 path <C,X>
  1168.  
  1169.      o    Domain A has two equal cost paths to X: <A,C,X> and <A,B,X>
  1170.  
  1171.      Both C1 and C2 inject a route to X within the domain C, and
  1172.      likewise A1 and A2 inject a route to X within the domain A.  Since
  1173.  
  1174.  
  1175.  
  1176. Varadhan                                                       [Page 21]
  1177.  
  1178. INTERNET DRAFT  (Expires September 15, 1993)                    March 93
  1179.  
  1180.  
  1181.      A3 and C3 see equal cost routes to X through A1, A2 and C1, C2
  1182.      respectively, a stable loop through ASBRs <A3, A2, C3, C2, A3>
  1183.      exists, which is used by these routers for load splitting with
  1184.      equal cost multi-path routing.
  1185.  
  1186. 11.  Author's  Address:
  1187.  
  1188.       Kannan Varadhan
  1189.       Internet Engineer, OARnet,
  1190.       1224, Kinnear Road,
  1191.       Columbus, OH 43212-1136.
  1192.       email: kannan@oar.net
  1193.  
  1194.       Yakov Rekhter
  1195.       T.J. Watson Research Center, IBM Corporation
  1196.       P.O. Box 218
  1197.       Yorktown Heights, NY 10598
  1198.       Phone: (914) 945-3896
  1199.       e-mail: yakov@watson.ibm.com
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232. Varadhan                                                       [Page 22]
  1233.  
  1234.